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EXECUTIVE SUMMARY 


The purpose of this Functional Requirements Document (FRD) is to compile the functional 
requirements needed to achieve the Access 5 Vision of “ operating High Altitude, Long 
Endurance (HALE) Unmanned Aircraft Systems (UAS) routinely, safely, and reliably in the 
national airspace system (NAS)” for Step 1. These functional requirements will be used by 
Access 5 to develop a minimum set of policies, procedures and standards that can be proposed to 
the Federal Aviation Administration (FAA) and various standards organizations for 
consideration. It is envisioned that this comprehensive body of work will enable the FAA to 
establish and approve regulations to govern safe operation of UAS in the NAS on a routine or 
daily "file and fly" basis. 

The approach used to derive the functional requirements found within this FRD was to 
decompose the operational requirements and objectives identified within the Access 5 Concept 
of Operations (CONOPs) into the functions needed to routinely and safely operate a HALE UAS 
in the NAS. Once these functions were identified, a functional architecture was developed to 
accommodate these functions. As a result, four major functional areas evolved to enable routine 
and safe UAS operations for an on-demand basis in the NAS. These four major functions are: 
Aviate, Navigate, Communicate, and Avoid Hazards. All of the functional requirements within 
this document can be directly traceable to one of these four major functions. Some functions, 
however, are traceable to several, or even all, of these four major functions. These cross-cutting 
functional requirements support the “Command / Control” function as well as the “Manage 
Contingencies” function. The requirements associated to these high-level functions and all of 
their supporting low-level functions are addressed in subsequent sections of this document. 
Where appropriate, rationale and justification has been provided to support each of the functional 
requirements within this FRD. 

To ensure the requirements are necessary and sufficient, validation and verification processes 
will be used throughout the Access 5 project. The validation process will ensure each of these 
requirements is unambiguous, correct, complete, consistent, operationally and technically 
feasible, and verifiable. The verification process will demonstrate that a potential solution can 
meet the low-level functional and performance requirements demonstrating that the system is 
ready for use in the operational environment. 

Several appendices are included at the end of this FRD to identify requirement traceability 
throughout the requirements hierarchy. Both tabular and graphic depictions of this traceability 
are provided. 
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1 INTRODUCTION 


1 .1 PURPOSE AND SCOPE 

The purpose of this Functional Requirements Document (FRD) is to compile the necessary 
functional requirements to achieve the Access 5 Vision of “ operating High Altitude, Long 
Endurance (HALE) Unmanned Aircraft Systems (UAS) routinely, safely, and reliably in the 
National Airspace System (NAS)” 1 . These requirements will then be used by Access 5 to develop 
the recommended policies, procedures and standards necessary for HALE UAS to have same- 
day “file and fly” access to the NAS. 

The scope of this FRD is focused on capturing the functional requirements specifically needed to 
meet the Access 5 Step 1 objective of routine operations within the NAS above 43,000 feet. 
These functional requirements were identified by performing a thorough functional analysis of a 
UAS, whereby the major functions of a UAS were identified and then organized into a functional 
architecture. To assist in this process, several work packages were created to develop the low- 
level functional requirements related to several of these major functional areas. Although Step 1 
of Access 5 may not have a specific Work Package associated with each functional area, those 
areas unique to unmanned aircraft have been the initial focus. 


1 .2 ACCESS 5 OVERVIEW 

Access 5 is a national project sponsored by the National Aeronautics and Space Administration 
(NASA) and Industry with participation by the Federal Aviation Administration (FAA), 
Department of Defense (DoD) and Department of Homeland Security (DHS) promoting the safe 
and reliable operation of HALE UAS within the NAS for civil and commercial applications. 
This team of government and industry partners are focusing their resources on developing the 
necessary policies, procedures, and standards to enable companies to apply for FAA certification 
and approval to operate their civil/commercial UAS in the NAS. 

The goal of Access 5 is to enable what government and industry leaders believe will ultimately 
be a robust civil and commercial market for HALE UAS. While Access 5’s primary focus is to 
address airspace access of unmanned aircraft within the domestic NAS, it is also working with 
the international community to ensure what is done in the United States will not inhibit the 
introduction of UAS into the global airspace in the future. 

Access 5 is taking an incremental approach for introducing HALE UAS into the NAS. HALE 
was chosen as the focus because HALE aircraft are more mature systems and can operate above 
most air traffic, making this class of UAS a good candidate for initial introduction into the NAS. 
It is believed, however, that Access 5 will also lay the groundwork for the future introduction of 
other classes of UAS. Access 5 will achieve its goal by systematically addressing access to the 
NAS in four discrete steps of increasing complexity and capability: 


1 Access 5 Project Readiness Review (PRR) Presentation Dallas, TX; February 10 - 11, 2004. 
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Step 1: Routine operations above Flight Level (FL) 430 through pre-coordinated airspace 
with emergency landings at pre-coordinated airports; and recommendations for obtaining an 
experimental certification 

Step 2: Routine operations above FL 180 through pre-coordinated airspace with emergency 
landings at pre-coordinated airports; and recommendations for obtaining a type certification 

Step 3: Routine operations above FL 180 through C, D, and E airspace with emergency 
landing at pre-coordinated airports; and recommendations for obtaining a special 
airworthiness certification 

Step 4: Routine operations above FL 180 through C, D, and E airspace with emergency 
landings at any UAS designated airport; and recommendations for obtaining a standard 
airworthiness certification 

1 .3 DOCUMENT ORGANIZATION 

This document is organized into the following sections: 

Section 1 - Introduction: States the background, purpose and scope of this requirements 

document, including its relationship to the Access 5 project. 

Section 2 - Access 5 Requirements Analysis Process: Identifies the hierarchical structure of 
requirements adopted by Access 5 and describes the approach used to develop the Operational, 
Functional, and Performance Requirements for a UAS. 

Section 3 - HALE UAS Description: Defines what comprises a HALE UAS and identifies the 
operational requirements needed for safe and routine UAS operations within the NAS. 

Section 4 - UAS Functional Analysis: Identifies the functional architecture used to capture the 
major functions of an unma nn ed aircraft system. 

Section 5 - UAS Functional Requirements: Specifies the functional requirements for a UAS 
in accordance with the Functional Architecture established in Section 4. 

Section 6 - Requirements Validation / Verification: Specifies the rationale for conducting 
verification of the functional requirements identified under this project and the different methods 
to be used. 

Section 7 - References: Provides the references used in the creation of this FRD. 

Appendix A - Acronyms: Provides a list of the acronyms used within this document. 

Appendix B - Definitions: Provides definitions for the unique words found within. 

Appendix C - UAS Requirements Wiring Diagram: Provides a wiring diagram of the UAS 
Functional Requirements showing traceability throughout every level of our UAS requirements. 

Appendix D - Operational/Functional Traceability Matrix: Provides a traceability Matrix 
between the Operational and Functional Requirements. 
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2 ACCESS 5 REQUIREMENTS ANALYSIS PROCESS 


2.1 REQUIREMENTS ANALYSIS 

Requirements Analysis involves defining the needs and objectives of a particular system in the 
context of how the system is employed, what type of environment it will be used within, and 
what type of system characteristics it is intended to possess 2 . The purpose of performing 
requirements analysis is extensive. First and foremost, requirements analysis should result in a 
clear understanding of the functions {what the system has to do), their interfaces ( environment in 
which the system will perform ) and their necessary level of performance ( how well the system 
should perform) in order to meet the intended operational concept of the system. 

2.2 REQUIREMENTS PERSPECTIVE 

The requirements that result from performing requirements analysis can be expressed in three 
different perspectives or views. These three views are: Operational, Functional, and Physical. 
The Operational View addresses how the system will serve its users and is useful when 
establishing requirements of “how well” and “under what condition.” The Functional View 
focuses on “what” the system must do to produce the required operational behavior. Lastly, the 
Physical View focuses on “how” the system is constructed and establishes the physical interfaces 
among operators and equipment as well as technology requirements 3 . 

Although all three views are essential to fully understand the customer’s needs and objectives for 
a system, Access 5 will only be considering the Operational and Functional perspectives. The 
Physical perspective is not being considered because Access 5 is not developing or certifying any 
specific unmanned aircraft system. Therefore, the physical components and interfaces are 
considered design specific and therefore outside the scope of Access 5. The Access 5 Concept of 
Operations (CONOPs) is intended to provide the Operational View, while the Access 5 
Functional Requirements Documents will provide the Functional View. 

2.3 REQUIREMENTS HIERARCHY 

There are several different levels or categories of requirements. The highest-level requirements 
are Operational Requirements. Functional, Performance, and Design requirements then flow 
from these. Functional requirements are derived from the Operational ones; Performance 
requirements are derived from the Functional ones; and Design requirements are derived from 
the Performance requirements; as shown in Figure 1. For added clarity, each of these different 
levels of requirements is defined in the subsequent sections. In addition, Figure 2 articulates 
what Access 5 deliverable will contain these different levels of requirements. 


2 Systems Engineering Fundamentals, Defense Acquisition University Press. Requirements Analysis, Pg. 36. 
January 2001. 

3 Ibid. Pg. 38-39. 
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Figure 1: Example of a Requirements Hierarchy 
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2.3.1 OPERATIONAL REQUIREMENTS 

Operational requirements define what is necessary for the system to operate within the existing 
rules and constraints (see the top tier of Figures 1 and 2). Since these rules and constraints do 
not currently exist for UAS, Access 5 is working very closely with the FAA and various 
standards organizations to help establish what policies, procedures, and standards UAS will be 
required to meet in the future. Specifically, the Access 5 operational requirements should 
identify where the system will be used, how the system will accomplish its mission objectives, 
and what environment the system will be expected to operate within 4 . This level of requirements 
is captured within the Access 5 CONOPs document. 

2.3.2 FUNCTIONAL REQUIREMENTS 

Functional requirements state the necessary task, action, or activity that must be accomplished. 
Regarding the requirements analysis process, functional requirements (what has to be done) 
should be used when performing functional analysis 5 . There may also be different levels of 
functional requirements. The high-level functional requirements provide the necessary 
functionality to meet the operational requirements, while the low-level functional requirements 
are functional requirements that are derived from the high-level functional requirements to 
provide further clarification. With respect to Access 5, the high-level functional requirements 
are captured within the Access 5 FRD (this document) and the low-level Functional 
Requirements are captured within the Work Package specific FRDs (see the 2 nd and 3 rd tiers of 
Figures 1 and 2). 

2.3.3 PERFORMANCE REQUIREMENTS 

Performance requirements define how well the system must perform its intended function (e.g. 
accuracy, fidelity, range, resolution, and response times) 6 . During requirements analysis, 
performance requirements are defined such that the functional requirement they relate to can be 
verified using a quantified performance value. The Access 5 Work Package specific FRDs will 
capture Performance “Guidelines” within the documents appendices as opposed to Performance 
Requirements. The reason for this distinction between requirements and guidelines is due to the 
nature of the requirements Access 5 is developing. Since Access 5 is not focused on any 
particular UAS architecture or platform it is very difficult to specify performance requirements 
that will accommodate all UAS. Therefore, performance guidelines are being suggested as the 
notional requirements that should be adequate for most platforms but may not satisfy all possible 
cases at different ends of the spectrum (see the 4 th tier from the top in Figures 1 and 2). 

2.3.4 DESIGN REQUIREMENTS 

Design requirements are the “build to” or “code to” requirements 7 for products and are very 
design and implementation specific. Since Access 5 is not certifying any platforms or designing 
any specific solutions, no Access 5 resources are being spent at this level of the requirements 
chain (see the bottom tier of Figures 1 and 2). 


4 Systems Engineering Fundamentals, Defense Acquisition University Press. Requirements Analysis, Pg. 36. 
January 2001. 

5 Ibid. 

6 Ibid. 


7 Ibid. 
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3 HALE UAS DESCRIPTION 


3.1 HALE UAS DEFINITION 

An Unma nn ed Aircraft System is an unmanned aircraft that is remotely operated from a control 
station by a pilot that issues command and control instructions to the aircraft, which are executed 
by an onboard flight management control system. A HALE UAS is an unmanned aircraft 
capable of performing mission objectives at an altitude above 18,000-feet mean sea level (MSL) 
with sufficient cruise capability to transit the NAS. 

Any UAS is comprised of three major elements as portrayed in Figure 3 below. These elements 
are: 1) the Control Station, 2) the Unmanned Aircraft, and 3) the Command/Control Links. 

• The Control Station (CS) is a site configured to allow the pilot in command of the UAS 
to operate and monitor all UAS operations conducted under his/her authority. The UAS 
pilot is considered to be an integral part of the Control Station. 

• The Unma nn ed Aircraft (UA) is the unmanned platform capable of flight in the air. This 
could include a fixed wing airplane, a helicopter, or a balloon. 

• The Command/Control (C2) Link is the two-way data link between the Control Station 
and the Unma nn ed Aircraft that is used to control the UA and monitor the health/status of 
onboard systems. 
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Figure 3: Notional Unmanned Aircraft System 
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3.2 ACCESS 5 OPERATIONAL REQUIREMENTS 

As discussed in Section 2, the very top level in the requirements hierarchy is the operational 
requirements level. These operational requirements should identify where the system will be 
used, how the system will accomplish its mission objectives, and what environment the system 
will be expected to operate within. The following table identifies the HALE UAS operational 
requirements. These requirements specify the operational capabilities needed by a HALE UAS 
to enable it to operate routinely and safely in the NAS. Table 1 captures these Operational 
Requirements as identified in the Access 5 CONOPs 8 . 


Table 1: Access 5 Operational Requirements 


Requirement 

Number 

Operational 

Requirement 

Overall 

Operational 

Requirement 

UAS shall operate routinely and safely in the NAS. 

01 

UAS shall be airworthy. 

01.1 

The UAS shall be registered with the FAA. 

01.2 

The UAS shall obtain and maintain a standard airworthiness certificate. 

01.3 

The UAS shall meet an equivalent level of safety to that of a manned general aviation 
aircraft. 

02 

UAS shall be operated safely in the NAS. 

02.1 

UAS operations shall comply with all applicable 14 CFR Part 91 requirements. 

02.2 

The UAS shall obtain and maintain the necessary operating certificates for 14 CFR Part 91 
commercial operations (maintenance, training, etc). 

02.3 

UAS flight operations shall be conducted under Instrument Flight Rules (IFR). 

02.4 

The UAS shall operate under the same separation standards required for manned aircraft 
per FAA 71 10.65. 

02.5 

An authorized and qualified pilot shall be responsible for the safe flight of each UA. 

02.6 

The UAS shall operate in a predictable manner similar to that of manned aircraft in the 
event of an emergency or other contingency situation. 

02.7 

UAS shall utilize authorized frequency spectrum for command, control, communications 
and payloads. 


These operational requirements are captured in this FRD because the UAS Functional 
Requirements discussed later within this document are directly related to one or more of these 
operational requirements. It is essential that each functional requirement be traceable to at least 
one of these Access 5 Operational Requirements. Appendix D provides a traceability matrix 
between these operational and functional requirements. 


8 Access 5 Concept of Operations, Version 2.0, Pg. TBD. Aug 2005. (This document is also being revised at the 
present time.) 
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4 UAS FUNCTIONAL ANALYSIS 

This section describes the framework used to perform the functional analysis on a UAS as well 
as the rationale used for utilizing this architecture. 


4.1 FUNCTIONAL ANALYSIS 

The purpose of functional analysis is to transform the functional, performance, and interface 
requirements that were identified through requirements analysis into a coherent description of 
system functions that the system must be capable of doing. These functions should be discrete 
actions (using action verbs) necessary to achieve system objectives 9 . 

In order to develop functional requirements for any system, a functional analysis of the system 
should be performed. Functional analysis provides a system description that becomes a 
framework for developing requirements and architectures. The Access 5 functional analysis 
examines the UAS functions and sub-functions necessary to accomplish the operational concept 
identified in the Access 5 CONOPs. This process is iterated until the system is completely 
decomposed into basic sub-functions, and each sub-function at the lowest level is completely, 
simply, and uniquely defined by its requirements. The result of this process is a functional 
architecture where system requirements can be identified, decomposed, and derived. 10 


4.2 FUNCTIONAL VS PHYSICAL ARCHITECTURE 

The previous version of the Access 5 FRD 11 separated each of the initial UAS functional 
requirements according to a physical architecture that was comprised of three major elements: 
(1) Air Vehicle Element, (2) Control Element and (3) Communications Element, ft was 
determined that many of these functional requirements could actually pertain to more than one of 
these physical elements. For example, one manufacturer may assign a collision avoidance 
function to the control station while another may prefer to implement that same function onboard 
the unmanned aircraft. Furthermore, assigning a functional requirement to one of the physical 
elements inadvertently promotes a particular design or implementation to the UAS industry. To 
prevent this from occurring, it was decided that a functional architecture would much better meet 
the needs of Access 5; particularly since Access 5 does not intend to certify any specific 
unmanned aircraft system. A functional architecture should therefore provide the necessary 
flexibility to the manufacturers by allowing each one the ability to decide where best to 
implement each function within their specific UAS. 


9 Systems Engineering Fundamentals, Defense Acquisition University Press. Requirements Analysis, Pg. 45. 
January 2001. 

10 “Section 4.4: Functional Analysis” NAS System Engineering Manual . Version 3.0, 30 September 2004 

11 Access 5 Functional Requirements Document, Revision 1, 5 September 2003. 
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4.3 UAS HIGH-LEVEL FUNCTIONS 

To determine what high-level functions Access 5 would use to capture the essence of an 
unmanned aircraft system, several different methods were proposed. The different methods 
considered included: Phases of Flight; Access 5 Work Packages (how the Access 5 Technology 
IPT is organized); NAS Functions of Communication, Navigation, and Surveillance (CNS); and 
Airworthiness & Operational Functions. 

While many of these proposed approaches could have been used, a concerted effort was made to 
select the best approach for meeting the various needs of Access 5. After several meetings 
between various Work Package representatives, it was determined that the best approach for 
meeting the needs of Access 5 was to decompose the UAS into 4 major functions: Aviate , 
Navigate, Communicate, and Avoid Hazards. A depiction of this high-level functional 
breakout is shown in Figure 4. 



Figure 4: UAS High-Level Functions 


The “Aviate, Navigate, Communicate, and Avoid Hazards” functions were chosen for several 
reasons. The most basic reason stems from a principle that every pilot is trained to adhere to. For 
anyone that has ever taken flying lessons, the first critical piece of information taught to any new 
trainee is the 3 major responsibilities of a pilot and the order (priority) in which these 
responsibilities should be performed. The first responsibility is to fly the plane (aviate), then fly 
it in the right direction (navigate), and finally state your intentions to others (communicate). 
Since the operational concept for a UAS is to operate in the NAS as any other type of aircraft, 
this paradigm makes sense for routine operations. In addition, the UAS also needs to be able to 
perform a function ensuring that no person or property in the air or on the surface is placed in 
danger. The function “Avoid Hazards” was therefore added to Aviate, Navigate and 
Communicate due to the necessity to ensure safety when introducing UAS into the NAS. This 
function is normally performed by the pilot on-board a manned aircraft. However, the separation 
of the pilot from the aircraft in a UAS places additional emphasis on this function. The success 
or failure of integrating UAS into the NAS may very well be dependent upon how well they can 
perform this particular function. 
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4.4 UAS LOW-LEVEL FUNCTIONS 

Once the high-level functions of the UAS were determined, a functional analysis was performed 
to decompose these into their respective low-level functions. These lower level functions are the 
focus of the remainder of this FRD (see Section 5), which attempts to capture the HALE UAS 
functional requirements and ensures they are traceable back to one of these high-level functions 
and at least one of the operational requirements listed in Table 1. 

While performing the functional analysis of a UAS, it became apparent that some functions were 
common to all four of the high-level functions. These cross-cutting functional areas included 
command/control, human systems interface, and contingency management. While the functional 
requirements pertaining to command/control and contingency management are discussed in 
Section 5.5 (Cross-Cutting Functional Requirements), the HSI functional requirements have been 
integrated into the appropriate sections under the Aviate, Navigate, Communicate and Avoid 
Hazards Functions. The rationale for keeping the HSI functional requirements together with the 
relevant functional area is because the human system interface is considered to be part of the 
function itself. If the function were implemented in a fully autonomous manner, then the human 
system interface requirement would not be necessary to support the higher level function. 

The figure on the following page depicts the UAS low-level functions subordinate to Aviate, 
Navigate, Communicate, and Avoid Hazards. In addition, the command/control and contingency 
management low level functions are shown as the large purple and orange blocks, respectively, 
that span the breadth of the functional architecture. The numbers within each block correspond 
to the corresponding paragraph numbers in Section 5. 
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5 UAS FUNCTIONAL REQUIREMENTS 

This section attempts to capture the functional requirements needed to operate HALE UAS 
safely and routinely in the NAS in accordance with the limitations established under the Access 
5 Step 1 objectives. Each of these functional requirements has been allocated to one or more of 
the high-level functions (Aviate, Navigate, Communicate, Avoid Hazards) used in developing 
the framework for the UAS functional architecture. 

At the highest level of this functional architecture, the UAS is identified as the object needing to 
perform the required function (i.e. “The UAS shall...”). However, as one looks deeper into the 
functional architecture, specific systems responsible for performing the function are identified as 
the object of the requirement (i.e. “The Communications System shall...” or “The Collision 
Avoidance System shall ...”). As it is used in this context, the word “System” could comprise 
functional elements from anywhere within the UAS. The word “System” should therefore be 
thought of in the broadest context possible, as it does not imply a single “black box”. The UAS 
pilot could even be part of any one of these Systems. 


5.1 AVIATE FUNCTIONAL REQUIREMENTS 

The UAS shall be able to aviate within the NAS. Aviating includes both controlling and 
monitoring the aircraft and all of its systems necessary for launch, climb, maneuver, cruise, 
descent, and recovery. Since Step 1 of Access 5 only addresses flight operations above FL 430 
the requirements for operating on the surface is reserved for future study. Figure 6 depicts the 
functional requirements comprising the overall Aviate Function of a UAS. 
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Figure 6: Aviate Functions 
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5.1.1 LAUNCH 

The UAS Aviate System shall be able to initiate flight within the NAS. The specific method 
used to initiate flight (such as taking off from a runway, being catapulted into the air, dropped 
from another aircraft, or being launched from a rocket) is considered a design decision and is not 
applicable at this level. 

5.1 .1 .1 Abort Launch 

The UAS Aviate System shall be able to abort a launch. Just prior to launch, the UAS 
should be able to determine when less than optimal conditions exist for launching the UA. 
If so, the UAS should have the capability to cancel the launch and try again at a later time. 
This ensures last minute changes in weather or obstructions near the launch area do not 
cause an accident or incident. 

5.1.2 MANEUVER 

The UAS Aviate System shall be able to maneuver the UA within the NAS. In order to aviate 
within the NAS, the UA may be required to change its flight path, ground path, or speed. 

5.1 .2.1 Maneuver in the Air 

The UAS Aviate System shall be able to maneuver the UA through the air. In order to 
aviate within the air, the UA may be required to change its flight path or speed. The typical 
method used to maneuver through the air involves controlling the aircraft’s flight controls 
and propulsion system. 

5.1 .2.1 .1 Change Altitude 

The UAS Aviate System shall be able to climb or descend to its intended altitude of 

operation. 

5.1 .2.1 .2 Change Heading 

The UAS Aviate System shall be able to turn left and right to specific headings. 

5.1 .2.1 .3 Change Speed 

The UAS Aviate System shall be able to change its airspeed. 

5.1 .2.2 Maneuver on the Surface 

The UAS Aviate System shall be able to maneuver the UA on the surface. In order to 
aviate along the surface, the UA may be required to change its ground path, or speed. The 
typical method used to maneuver on the surface involves ground steering, manipulating the 
flight controls and adjusting the propulsion system. Even such items as a tow truck or 
ground crew could be used to maneuver the UA on the surface. 

5.1 .2.2.1 Change Ground Path 

The UAS Aviate System shall be able to change the direction of its ground path. 
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5. 1.2. 2. 2 Change Speed 

The UAS Aviate System shall be able to change the speed of its ground path. 


5.1 .2.3 Enable Pilot to Maneuver UA (HSI FI) 

The Human System Interface shall enable the pilot to command flight maneuvers. Flight 
maneuvers can include, but are not limited to changing the aircraft’s attitude, altitude, 
heading, velocity, and vertical velocity. 

5.1 .2.4 Enable Pilot to Monitor Flight Operations (HSI F2) 

The Human System Interface shall convey information to the pilot to monitor flight 
operations. This requirement enables the pilot to determine if the aircraft is following the 
intended flight or ground path. This applies regardless of whether the UAS is autonomously 
flying to the next waypoint or the pilot is the one inputting specific commands. 


5.1.3 CRUISE 

The UAS Aviate System shall be able to conduct steady-state (non-accelerating) flight within 
the NAS. Since Step 1 of Access 5 assumes UA will operate under instrument flight rules (IFR), 
they will need to be able to comply with ATC instructions that may include being told to hold 
altitude or maintain heading. This requirement, as worded, includes cruise-climb as a type of 
steady state, non-accelerating flight. 

5.1.4 RECOVER 

The UAS Aviate System shall be able to safely conclude flight operations within the NAS. The 
specific method used to conclude flight (such as landing on a runway/landing pad, being caught 
by a net, or controlled flight into terrain) is considered a design decision and is not applicable at 
this level. 

5.1 .4.1 Recover During Normal Operations 

The UAS Aviate System shall be able to land/recover during normal operations. Normal 
operations include all cases that don’t involve dealing with a contingency or anomalous 
condition. 

5.1 .4.2 Recover During Non-normal Operations 

The UAS Aviate System shall be able to land/recover during non-normal operations. 
Recovery during non-normal operations my include a variety of techniques to include using 
parachutes, pre-programmed commands, flight termination systems, or controlled flight into 
terrain. 

5.1 .4.3 Go Around 

The UAS Aviate System shall be able to perform a go around maneuver when 
landing/recovery operations warrant it. Just prior to recovery, the UAS should be able to 
determine when less than optimal conditions exist for recovering the UA. If so, the UAS 
should have the capability to cancel the recovery and try again. This ensures last minute 
changes in weather or obstructions to the recovery area do not cause an accident or incident. 
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5.1.5 MAINTAIN STRUCTURAL INTEGRITY 

The UAS Aviate System shall maintain structural integrity as it transits the NAS. Although 
further details related to this subject area are reserved for future study, it is still an essential 
element for ensuring airworthiness. 


5.2 NAVIGATE FUNCTIONAL REQUIREMENTS 

The UAS shall be able to navigate within the NAS. The ability to navigate infers the UAS is 
capable of maintaining navigational control, which involves maintaining knowledge of the 
current position, the destination, and the four dimensional path (latitude, longitude, altitude, 
time) to the destination. Navigation can be accomplished both strategically and tactically. While 
a traditional flight plan requires more time to complete and would be considered strategic, in- 
flight maneuvering would be considered a form of tactical navigation. Figure 7 depicts the 
functional requirements comprising the overall Navigate Function of a UAS. 




Figure 7: Navigate Functions 


5.2.1 DEVELOP MISSION PLAN 

The UAS Navigation System shall develop a mission plan to cover normal operations and 
contingencies. This requirement ensures the UAS can develop a strategic plan for getting to its 
intended destination. 
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5.2.1 .1 Access Mission Planning Data (MP FI) 

The UAS Mission Planning System shall access information needed to conduct a flight. 

5.2.1 .2 Evaluate Mission Planning Data (MP F2) 

The UAS Mission Planning System shall evaluate information needed to conduct a flight. 

5.2.1 .3 Create a Mission Plan (MP F3) 

The UAS Mission Planning System shall create a mission plan to include contingency 
routes or route segments. 

5.2.1 .4 Record Mission Plan (MP F4) 

The UAS Mission Planning System shall record the mission plan in a manner required by 
the unmanned aircraft before flight. 

5.2.1 .5 Provide Required Information to the ATM System (MP F5) 

The UAS Mission Planning System shall submit a flight plan to the air traffic 
management (ATM) System. 


5.2.2 IDENTIFY CURRENT POSITION 

The UAS Navigation System shall be able to identify the current three-dimensional position 
(i.e. latitude, longitude, altitude) of the UA with enough accuracy to fly under instrument 
flight rules ( IFR ). It is critical for the navigation system to be able to identify its current 
position so it may determine how to get to where ever it needs to go. 


5.2.3 DETERMINE HOW TO TRANSITION TO DESTINATION 

The UAS Navigation System shall be able to determine how to transition to its desired 
destination. This is necessary to ensure the UA can determine the next waypoint in accordance 
with the current flight plan. 


5.2.4 PRODUCE NAVIGATION COMMAND 

The UAS Navigation System shall be able to produce navigation commands in accordance 
with the current flight plan. The navigation command is used by the Aviate Function to 
actually fly the UA along the flight plan to the desired destination in accordance with the current 
flight plan. 


5.2.5 EXECUTE NAVIGATION COMMAND 

The UAS shall execute the navigation command. This requirement involves the physical 
change in state necessary to implement the navigation command (moving control surfaces, 
adjusting speed, etc.). This navigation functional requirement is actually performed by other 
functions within the UAS functional architecture such as the Aviate / Maneuver function. 
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5.2.6 CONVEY NAVIGATIONAL STATUS 

The UAS Navigation System shall convey the navigational status of the executed command. 
This requirement is the foundation for the navigate function in that it identifies where the aircraft 
is flying in relation to the airspace around it. After this information is conveyed, other functions 
within the UAS can determine if the aircraft is following the flight plan or if a correction is 
needed. 

5.2.6. 1 Convey Navigational Information to the Pilot (HSI F4) 

The UAS Human System Interface shall convey navigational information to the pilot to 
determine position, heading, course, speed, and altitude. 


5.2.7 UPDATE FLIGHT PLAN 

The UAS Navigation System shall allow the flight plan to be updated in real time throughout 
the mission. This requirement is necessary because many HALE UAS missions are able to last 
for several days or even weeks. During these extended missions, the Mission Planning System 
needs to have a capability to modify the original flight plan as necessary. 

5.2.7. 1 Pilot Updates to Flight Plan (HSI F5) 

The UAS Human System Interface shall enable the pilot to update the UAS’s flight plan. 
This requirement is necessary because it allows the pilot to change the course, speed, and/or 
altitude of the unmanned aircraft for a number of reasons that include following an Air 
Traffic Control (ATC) directive, a change in its mission/destination, bad weather along the 
flight path, or based upon the pilot’s or system’s assessment of a possible collision. 


5.3 COMMUNICATE FUNCTIONAL REQUIREMENTS 

The UAS shall be able to communicate (data or voice) with all entities needed to maintain safe 
and reliable UAS operations. These entities could be both internal and external to the UAS. 
While external entities would typically include ATC and other aircraft, internal entities could 
include ground support, maintenance, mission control, other control stations (hand-off), etc. 
Figure 8 depicts the functional requirements comprising the overall Communicate Function of a 
UAS. 
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Figure 8: Communicate Functions 


5.3.1 COMMUNICATE WITHIN THE UAS 

The UAS Communication System shall provide internal communications connectivity between 
functions within the UAS. As mentioned above, this communications could be between the 
pilot and ground support, maintenance, mission control, or other control stations (hand-off). 

5.3.1 .1 Transmit Information within the UAS 

The UAS Communication System shall be able to transmit voice/data communications to 
entities within the UAS. 

5.3.1 .2 Receive Information within the UAS 

The UAS Communication System shall be able to receive voice/data communications from 
entities within the UAS. 


5.3.2 COMMUNICATE OUTSIDE THE UAS 

The UAS Communication System shall provide external communications connectivity with 
entities outside the UAS. To ensure the necessary information is conveyed between the UAS 
pilot and ATC or some other aircraft, some means of communications is needed to ensure this 
function can occur throughout the entire flight profile. 
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5. 3.2.1 Tune Radio to the Assigned Channel (C3-ATC FI) 

The UAS ATC Communication System shall be able to tune to an assigned ATC voice 
channel corresponding to the ATC sector the UA is flying within. Depending on the 
particular Link Type implemented, this may involve remotely tuning a VHF radio on the 
UA or switching connectivity to a particular ATC facility. 

5. 3.2.2 Receive/Monitor ATC Voice Channel Activity (C3-ATC F2) 

The UAS ATC Communication System shall be able to continuously monitor voice 
channel activity, including controller and other pilot voice activity, on its assigned 
channel. This sets the requirement for “party line” for ATC air to ground (A/G) radio talk 
groups and augments 14 CFR 91 regulations. The requirement to be able to hear other pilots 
and to be able to talk to other pilots on the same assigned channel (i.e. within the “talk 
group”) is not explicitly specified in the Federal Air Regulations nor in FAA standards, but 
is common practice and promotes situational awareness. The Step 1 HALE UAS ATC 
Communication System should not preclude this capability. 

5. 3. 2. 2.1 Receive Using Human Systems Interface (HSI F6) 

The Human System Interface shall enable the pilot to receive communications from 
ATC. 

5. 3.2. 3 Transmit Voice (C3-ATC F4) 

The UAS ATC Communication System shall be able to transmit pilot voice 
communications on an assigned ATC channel. This requirement is necessary because it 
meets 14 CFR Part 91.135, “Each pilot must maintain two-way radio communications with 
ATC while operating in Class A airspace.” 12 While transmitting voice traffic to other 
aircraft in the area is not a hard requirement, it is strongly recommended that the voice being 
transmitted to ATC should not be precluded from being heard by other pilots on the 
assigned channel. 

5. 3. 2. 3.1 Transmit Signal Indication (C3-ATC F3) 

The UAS ATC Communication System shall be able to generate a Transmit Signal 
Indication to initiate ATC communications. For configurations employing VHF 
subsystems this corresponds to the Push to Talk (PTT) signal, which the voice switch 
and/or VHF transmitter needs to initiate communications. For a satellite channel, link 
initiation and channel signaling are different from the VHF case; however a PTT 
indication still has to be sent by the pilot microphone/headset to the UAS VHF 
subsystem by way of the pilot - Satellite Subsystem link. 

5. 3. 2. 3. 2 Transmit Only During Transmit Signal Indication (C3-ATC F5) 

The UAS ATC Communication System shall be able to transmit ATC voice 
communications only for the duration of a pilot PTT ( transmit indication signal) 
event. This is necessary because this is how existing simplex VHF A/G radios work 
today to access the channel. 


12 “Part 91.135: Operations in Class A Airspace” FAR/AIM 2005 . 2005 
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5.3.2.3.3 Entry Into a Talk Group (C3-ATC F6) 

The UAS ATC Communication System shall allow any U AS/pilot, operating in the 
correct mode, entry into any Talk Group within the Talk Group's service volume. 
This is to ensure that the pilot can enter a Talk Group regardless of whether or not the 
pilot was instructed to do so by the air traffic controller. For example, in the case 
where the pilot has lost communication with its own Talk Group, it should still be able 
to access another Talk Group. 

5. 3. 2. 3.4 Transmit Using Human Systems Interface (HSI F6) 

The Human System Interface shall enable the pilot to transmit communications to 
ATC. 

5. 3.2.4 Coexist With Other Existing NAS Systems (C3-ATC F7) 

The UAS ATC Communication System shall cooperatively coexist w/ other existing NAS 
systems. The UAS ATC Communication System must not introduce any harmful radio 
frequency interference (RFI) to compromise the current NAS performance. 

5. 3. 2.4.1 Limit Interference (C3-ATC F7a) 

The UAS ATC Communication System shall not generate harmful interference to 
other NAS systems (e.g., navigation, landing, and surveillance) 

5.3.2.4.2 Use Allocated Spectrum (C3-ATC F7b) 

The UAS ATC Communication System shall operate under the existing RFI 
environments. 

5. 3.2. 5 Transmit Transponder Data 

The UAS Communication System shall be able to transmit altitude encoded transponder 
data. This requirement is necessary because it meets 14 CFR Part 91.215, “No person may 
operate an aircraft in Class A, B, or C airspace unless that aircraft is equipped with an 
operable coded radar beacon transponder”. 13 This is also necessary to execute the Avoid 
Hazard requirement for being detectable to other NAS users (see requirement 5.4.2. 1) 

5. 3. 2. 5.1 Select / Modify Transponder Code 

The UAS Communication System shall allow the pilot to select/modify the 
transponder code. 

5. 3. 2. 5. 2 Enable / Disable Reporting Capability 

The UAS Communication System shall allow the pilot to enable/disable the altitude 
reporting capability. 

5. 3.2. 6 Receive Transponder Data 

The UAS Communication System shall be able to receive altitude encoded transponder 
data. This is necessary to execute the Avoid Hazard requirement to detect cooperative 
traffic (see requirement 5.4. 2. 3) 


13 “Part 91 .215: ATC Transponder and altitude reporting equipment and use” FAR/ AIM 2005 . 2005 
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5.4 AVOID HAZARDS FUNCTIONAL REQUIREMENTS 

The UAS shall avoid hazards while operating in the NAS. These hazards include obstacles on 
the surface, other traffic (both airborne and on the ground), and severe weather. Figure 9 depicts 
the functional requirements comprising the overall Avoid Hazards Function of a UAS. 
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Figure 9: Avoid Hazards Functions 

5.4. 1 AVOID COLLISIONS WITH THE SURFACE 

The UAS Avoid Hazards System shall be able to avoid collisions with the surface of the earth. 
Surface not only includes the ground itself, but also bodies of water and obstacles on the surface. 
Step 1 of Access 5 only addresses collision avoidance with other aircraft above Flight Level FL 
430 and reserves defining the requirements for collisions with the surface and obstacles on the 
surface for a future Step. 

5.4.1 .1 Avoid Collisions with Terrain 

The UAS Avoid Hazards System shall be able to avoid unplanned impact with terrain. 
Terrain includes the ground itself, natural land formations, bodies of water, and trees. 
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5.4.1 .2 Avoid Collisions with Obstructions on the Ground 

The UAS Avoid Hazards System shall be able to avoid unplanned collisions with 
obstructions while transiting the NAS. Obstructions include vehicles, humans, animals, 
and man-made structures such as buildings or towers. 


5.4.2 AVOID COLLISIONS WITH OTHER AIRCRAFT 

The UAS Avoid Hazards System shall be able to avoid collisions with other aircraft. Step 1 of 
Access 5 has established several constraints on the collision avoidance function. First and 
foremost, Step 1 assumes that the pilot will initiate all avoidance maneuvers, thereby prohibiting 
autonomous maneuvers. Autonomous collision avoidance maneuvers will be addressed in a 
future Step. In addition, since Step 1 only involves flight above FL430, airborne collision 
avoidance is all that was addressed. The detailed requirements dealing with collisions on the 
surface have been postponed for a future Step. 

5.4.2. 1 Avoid Collisions by Being Detectable to Other Traffic 

The UAS Avoid Hazards System shall avoid collisions with other aircraft by being 
detectible to other traffic in its proximate area. The UAS being detectible is essential in 
situations where the other aircraft is the one maneuvering to avoid the potential collision. 
Examples of this may include the UAS employing special coloring, markings, lights, active 
transmissions, and/or other means to enhance visibility/detectability of the UA to other 
traffic. 

5.4.2.2 Avoid Collision Threats Identified by ATC 

The UAS Avoid Hazards System shall be able to avoid collisions with other aircraft by 
maneuvering the UA in accordance with separation guidance provided by ATC. This 
requirement ensures the UAS is able to respond in accordance to traffic advisories provided 
by the appropriate air traffic authorities. 

5.4.2. 3 Avoid Collision Threats Identified by Collision Avoidance System 

The UAS Avoid Hazards System shall be able to avoid collisions with other aircraft by 
utilizing sense and avoid information. This requirement ensures the UAS is able to sense 
and avoid aircraft posing a potential collision threat. Although Step 1 of Access 5 only 
deals with avoiding cooperative aircraft using a pilot to initiate the maneuver, these 
functional requirements are worded broad enough such that they can accommodate the 
cooperative/non-cooperative case as well as man-in-the-loop/autonomous initiated 
maneuvers. 

5.4.2.3.1 Detect Traffic (CA FI) 

The UAS Collision Avoidance System shall detect traffic within its surveillance 
volume. The size of the surveillance volume is defined in accordance to the UA’s 
flight performance characteristics (airspeed, climb/descent rate, turn rate, etc.) as well 
as the flight characteristics of the potential traffic found within the UA’s operating 
environment. For Step 1, this refers only to cooperative traffic, which is defined as 
other aircraft that broadcast positional information using an altitude-encoding 


23 



transponder. In the very near future, this may also include technologies such as 
Automatic Dependent Surveillance - Broadcast (ADS-B). 

5.4. 2. 3. 2 Track Traffic (CA F2) 

The UAS Collision Avoidance System shall track the detected traffic. A “track” is 
established when a state estimate is developed with sufficient confidence. This 
estimate includes the traffic element’s position and velocity vector. 

5.4. 2. 3. 3 Evaluate Collision Potential (CA F3) 

The UAS Collision Avoidance System shall evaluate the potential for collision with 
each traffic element being tracked, including the assessment of existing collision 
threats. This requirement ensures all traffic being tracked is evaluated against some set 
of criteria enabling the system to determine collision potential. 

5.4. 2. 3.4 Prioritize Collision Threats (CA F4) 

The UAS Collision Avoidance System shall prioritize the traffic posing the most 
immediate collision threat. Traffic elements that have been deemed collision threats 
should be ranked based on time to collision, or some other similar criteria. 

5.4. 2. 3. 5 Determine Avoidance Maneuver (CA F5) 

The UAS Collision Avoidance System shall determine an avoidance maneuver that 
prevents a collision. The role of the pilot in CA F5 may vary depending on policy or 
design decisions: 

A) The pilot may determine the maneuver without assistance from any collision 
avoidance logic. 

B) The pilot may take into consideration the information provided by collision 
avoidance logic to help make a determination. 

C) The pilot may solely rely upon the maneuver determined by the collision 
avoidance logic. 

D) The pilot may have no interaction with the maneuver decision whatsoever. In 
Access 5, Step 1, option D is removed from consideration since autonomous 
maneuvers have been assumed to be out of scope. 

5.4.2.3.5.1 Convey threat information to the Pilot (HSI F7a) 

The UAS Human System Interface shall convey threat information to the pilot to avoid 
collisions with other aircraft. Since Step 1 of Access 5 assumes the pilot is responsible 
for initiating any avoidance maneuver, the pilot must have the necessary information 
needed to properly assess the collision situation and determine an appropriate avoidance 
maneuver. 

5.4. 2. 3. 6 Command Maneuver (CA F6) 

The UAS Collision Avoidance System shall command an appropriate avoidance 
maneuver. For Step 1 it is assumed that the pilot is part of the UAS CA function and 
will initiate the maneuver, since autonomous maneuvers are outside the scope of Step 1 . 
The commanded maneuver can include initiating a new maneuver, continuing an 
ongoing maneuver, or terminating an avoidance maneuver if a collision threat no longer 
exists. 
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5.4.2.3.6.1 Control the Collision Avoidance System (HSI F7b) 

The UAS Human System Interface shall enable the pilot to control the Collision 
Avoidance System. Since Step 1 of Access 5 assumes the pilot is responsible for 
initiating any avoidance maneuver, the pilot must have the ability to configure the 
collision avoidance system settings as well as initiate/modify/discontinue an avoidance 
maneuver. 

5.4. 2. 3. 7 Execute Maneuver (CA F7) 

The UAS shall perform the commanded maneuver. This CA functional requirement is 
performed by the maneuver function located within the “Aviate” portion of the UAS 
functional architecture. 


5.4.3 AVOID HAZARDOUS WEATHER 

The UAS shall be able to avoid hazardous weather while flying in the NAS. Hazardous 
weather is defined as any atmospheric or space environment phenomena that could be 
detrimental to the UAS mission. Hazardous aviation weather for the purposes of Step 1 typically 
includes thunderstorms, icing conditions, turbulence, or massive solar ejections. However, this 
may vary based on the structural characteristics of the UA being flown, ft is important to note 
that the primary need for the UAS avoiding hazardous weather is to prevent the UA from 
harming people or property, not for self preservation of the UA. 

5. 4. 3.1 Maintain Weather Awareness 

The UAS Weather Awareness System shall maintain awareness of hazardous weather 
along the entire route of flight. The UAS should be able to routinely access pertinent 
aviation weather information to include atmospheric and space weather data. This 
requirement ensures the UAS pilot has access to the necessary weather information 
resources such as ATC and/or packaged weather products, throughout the entire route of the 
flight. 

5.4.3. 1 .1 Gather Weather Information 

The UAS Weather Awareness System shall gather all necessary weather information 
for the entire route of flight This information should be gathered for the altitude at 
which the UAS will be operating as well as the area below the UAS in case descent 
through the lower airspace is required. It is assumed that the UAS pilot is part of the 
UAS Weather Awareness System. 

5.4.3. 1 .1 .1 Request weather information (HSI F8b) 

The UAS Human System Interface shall enable the pilot to request weather 
specific to a current or future flight plan. 

5.4.3. 1 .1 .2 Convey weather information to the UAS Pilot (HSI F8a) 

The UAS Human System Interface shall convey weather information to the 

pilot. 
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5.4.3. 1 .2 Evaluate Potential for Weather Conflicts 

The UAS Weather Awareness System shall evaluate the potential for flying into 
hazardous weather situations. This requirement enables the UAS pilot to plan for 
hazardous weather along the route of flight utilizing all available weather resources. 

5. 4. 3.2 Coordinate Weather Avoidance Maneuver 

The UAS Weather Awareness System shall coordinate with ATC the appropriate avoidance 
maneuver that prevents the UA from flying through the hazardous weather. The UA will 
always be flying under Instrument Flight Rules and, therefore must coordinate any deviation 
of the current flight path with ATC. 

5. 4. 3. 3 Command Weather Avoidance Maneuver 

The UAS Weather Awareness System shall be capable of commanding an appropriate 
maneuver to avoid the hazardous weather. It is assumed that the UAS pilot, as part of the 
UAS Weather Awareness System, will initiate the maneuver since autonomous maneuvers 
are outside the scope of Step 1. The commanded maneuver can include initiating a new 
maneuver, continuing an ongoing maneuver, or terminating an avoidance maneuver if 
hazardous weather no longer exists. 

5.4. 3. 3.1 Control the Weather Awareness System (HSI F8c) 

The UAS Human System Interface shall enable the pilot to control the Weather Awareness 
System. The pilot must have the ability to configure the Weather Awareness System settings as 
well as initiate, modify, or discontinue and avoidance maneuver. 

5. 4. 3. 4 Execute Weather Avoidance Maneuver 

The UAS shall perform the commanded weather avoidance maneuver. This functional 
requirement is actually performed by the maneuver function located within the “Aviate” 
portion of the UAS functional architecture. 

5.5 CROSS-CUTTING FUNCTIONAL REQUIREMENTS 

As previously discussed and as displayed in Figure 5 above, there are several functions that 
cross-cut through the major 4 functions (Aviate, Navigate, Communicate, Avoid Hazards) that 
establish the backbone of the UAS functional architecture. These cross-cutting functional areas 
pertain to Command/Control (C2) and Contingency Management (CM). Figure 10 depicts the 
functional requirements comprising the cross-cutting functions for C2 and CM. 
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5.5.1 COMMAND / CONTROL 

The UAS shall be able to command/ control the UA as it transits the NAS. This requirement is 
intended to ensure the UAS provides a 2-way command and control (C2) link between the UA 
and the Control Station for the purpose of maintaining safe UAS operations. Being able to 
command/control the UA from a remote location is one of the major differences between 
manned and unmanned aircraft 

5.5.1 .1 Exchange Information (C2 FI) 

The UAS Command/Control System shall perform information exchanges for UAS 
operations. The C2 Communications System is the conduit for exchanging information 
between the Control Station and UA. The C2 links are typically implemented with, but not 
limited to, modem digital communications via LOS or BLOS links. The UAS provides a 2- 
way C2 communication link between the UA and the Control Station. 

5.5.1 .1 .1 Uplink Information (C2 Fl.l) 

The UAS Command/Control System shall provide an uplink between the UA and 
Control Station. The uplink is the data transmission from the Control Station to the UA. 
The transmissions provide directives and information to the UA and include commands, 
messages, and related data. These transmissions must be achieved in a timely manner to 
ensure safety of flight. 
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5.5.1 .1 .2 Downlink Information (C2 F1.2) 

The UAS Command/Control System shall provide a downlink between the UA and 
Control Station. The downlink is the data transmission from the UA to the Control 
Station. The transmissions provide necessary and timely data for the pilot to conduct 
safe flight operations. The data may contain telemetry, situation awareness, health and 
status, and other data as needed. 

5.5.1 .1 .3 Consistent Operations (C2 F1.3) 

The UAS Command/Control System shall ensure cohesive and consistent uplink and 
downlink operations. It is critical that messages that are initiated for sending are 
received undamaged and within enough time to be useful. The uplink and downlink 
operations must work together smoothly to achieve these goals. 

5.5.1 .2 Control UA Flight Operations (C2 F2) 

The UAS Command/Control System shall control the UA during flight operations. Since 
UA do not have an onboard pilot, the C2 Communications System is vital to transmit 
information that enables the pilot to direct UA operations and ensure flight safety in the 
NAS 

5.5.1 .2.1 Provide Situational Awareness and Health & Status (C2 F2.1) 

The UAS Command/Control System shall provide situational awareness and health & 
status of the UA to the Control Station. Since the UA pilot is off board the aircraft at 
all times and “flies” the aircraft from the Control Station, the UA must transfer onboard 
information to the pilot. The transferred data includes health and status of the aircraft 
along with in-flight situation awareness information from onboard sensors and systems. 

5.5.1 .2.2 Provide C2 Directives (C2 F2.2) 

The UAS Command/Control System shall provide C2 directives to the UA. Since the 
UA pilot is off board the aircraft at all times and “flies” the aircraft from the Control 
Station, the pilot must transfer directives to the UA. The directives include flight 
commands and requests for data. 

5.5.1 .2.3 Prioritize Information Exchanges (C2 F2.3) 

The UAS Command/Control System shall provide the capability to prioritize C2 
information exchanges. There are several kinds of messages conveyed in the C2 link. 
Some of the messages and information will be more critical than others to control safe 
flight, depending on the operational environment and events. It is crucial that the C2 
Communications System transfer higher priority messages before transferring lower 
priority messages. In effect, higher priority messages will usually be transferred with 
less delay than lower priority messages. 

5.5.1 .2.4 Coexist Within the NAS (C2 F2.4) 

The UAS Command/Control System shall provide protection means for the C2 
communications to coexist with current NAS systems and operations. The C2 link is 
new to the NAS infrastructure and thus must not introduce any harmful radio frequency 
interference (RFI) to compromise the current NAS performance. 
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5.5.1 .2.5 Distinguish Between UA’s (C2 F2.5) 

The UAS Command/Control System shall provide the ability to distinguish each UA. 
It is paramount to flight safety and task success to be able to identify, communicate, and 
control each UA without any ambiguity. 

5.5.1 .3 Prevent Unauthorized Operation of the UAS (C2 F3) 

The UAS Command/Control System shall ensure no un-authorized person(s) or system(s) 
assume control of the UAS. Security of the C2 link is important to the safety of the UA and 
other aircraft and personnel in the NAS. Only authorized users should have access to the C2 
link to perform message transfers. The transmissions themselves must not be corrupted, 
changed, or denied; to do so could jeopardize safety as well as task success. 

5. 5. 1.3.1 Physical Security 

The UAS Command/Control System shall prevent physical interruption or 
interference with the pilot. 

5.5.1 .3.2 Link Security (C2 F3.2) 

The UAS Command/Control System shall prevent un-authorized person(s) or 
systems(s) from assuming control of the UAS command/control link. 

5.5.1 .3.3 Link Interference (C2 F3.3) 

The UAS Command/Control System shall prevent un-authorized person(s) or 
systems(s) from interfering with the UAS command/control link. 

5.5.1 .4 Provide Link Connectivity (C2 F4) 

The UAS Command/Control System shall provide C2 link connectivity. The overall safety 
of the UAS depends greatly upon the ability of the UAS to maintain connectivity between 
the UA and Control Station. 

5.5.1 .4.1 Transitioning Between LOS/BLOS (C2 F4.1) 

The UAS Command/Control System shall provide C2 Communications while 
transitioning between LOS and BLOS operations. Typically, the UA flies away from 
LOS and to BLOS with respect to the Control Station. The C2 Communications 
System must be capable of providing communications for both LOS and BLOS 
conditions, including the transition between them. Due to physical constraints that may 
exist, such as during transitions between satellites or at the edge of a satellite footprint, 
scheduled and/or predictable link dropouts may be acceptable as long as the dropouts 
do not compromise the UAS’s ability to comply with other functional requirements. 

5.5.1 .4.2 Transitioning Between Control Stations (C2 F4.2) 

The UAS Command/Control System shall provide C2 Communications while 
transitioning between different Control Stations. It is possible that more than one 
Control Station is employed during the course of UA flight, though there is no 
requirement to have more than one Control Station. The C2 Communications System 
must be capable of providing communications between the UA and the Control Station 
in control, including the transition from one Control Station to another. 
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5.5.2 MANAGE CONTINGENCIES 

The UAS shall manage contingencies to reduce the likelihood of loss of life or damage to 
personal property. Contingencies include failures of avionics and other equipment within the 
UAS, loss of communications both internal and external to the UAS, and failure of pilot or 
operators to respond to critical events within the UAS. Contingency management involves 
evaluating non-normal events, deciding on the proper course of action (plan) and successfully 
executing the mitigation plan. 

5. 5. 2.1 Identify System Status 

The UAS Contingency Management System shall be able to identify the health and status 
of all flight critical systems within the UAS. Flight critical systems are those systems 
deemed necessary to the safe operation of the UAS for routine operations in the NAS. 

5. 5. 2.1 .1 Convey System Status to the Pilot (HSI F3) 

The UAS Human System Interface shall convey information to the pilot to determine 
the health and status of the UAS. This requirement is necessary because it provides 
essential information to the pilot to determine if systems on board the unmanned aircraft 
are accepting updates and functioning properly. Any degradation of a system that could 
decrease the UAS’s ability to fly safely in the NAS should be brought to the pilot’s 
attention. 

5. 5. 2.2 Determine Contingency Event 

The UAS Contingency Management System shall be able to determine the contingency 
event that took place. This requirement ensures the non-normal event can be evaluated and 
assessed. 

5. 5. 2. 3 Prioritize Contingency Events 

The UAS Contingency Management System shall be capable of prioritizing simultaneous 
contingencies so the most critical one can be addressed first. Although unlikely, the UAS 
must be able to handle simultaneous contingencies and address the most critical on first. 

5. 5. 2. 4 Produce Mitigation Command 

The UAS Contingency Management System shall produce the command necessary for 
mitigating the contingency. This mitigation command is intended to re-establish an 
improved operational condition. Once safe operational conditions are established the UA 
could continue on its original flight path or transition to a location where it may be 
recovered. 

5. 5. 2.4.1 Enable Pilot to Manage Contingencies (HSI-F9) 

The UAS Human System Interface shall enable the pilot to manage contingencies. 
Each contingency that arises will require the appropriate information be conveyed to the 
pilot, thereby enabling the pilot to respond to contingencies in a predictable manner. 
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5. 5. 2. 5 Execute Mitigation Command 

The UAS Contingency Management System shall support execution of the command 
produced for mitigating the contingency. This mitigation command will most likely be 
performed by some other system or function within the UAS. 
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6 REQUIREMENTS VALIDATION / VERIFICATION 

Validation and verification is the System Engineering process that confirms whether the system 
requirements are correct and satisfied. According to the NAS Systems Engineering Manual , the 
validation process confirms that the system requirements are unambiguous, correct, complete, 
consistent, operationally and technically feasible, and verifiable; while the verification process 
ensures that the solution under test can meet the lower-level functional and performance 
requirements demonstrating that the system is ready for use in the operational environment for 
which it is intended 14 . This section describes how Access 5 intends to use both of these 
processes for validating and verifying our HALE UAS requirements. 


6.1 WHY VALIDATION IS IMPORTANT TO ACCESS 5 

The primary objective of the validation process is to ensure that requirements are correct and 
complete. Correctness of a requirements statement means the absence of ambiguity or error in 
its attributes. Completeness of a requirements statement means that no attributes have been 
omitted and those stated are essential and traceable 15 . Successful validation confirms that the 
identified requirements are justified, relevant, and logically correct in terms of the stake holder’s 
needs and operating environment. 

The validation process should be repeated incrementally at all stages of requirements 
development to ensure that the requirements at all levels are consistent with the intended 
mission. Since these requirements are hierarchical in nature and developed in increasing detail, 
validation is a staged process. Thus, as each level of requirements is developed, the 
requirements at that level undergo validation, after which each validated requirement undergoes 
verification. 

Access 5 intends to conduct validation in order to demonstrate that the requirements for a UAS 
are clearly understood and that it is operationally and technically feasible (i.e. not beyond the 
laws of physics). Before any requirement gets verified, it must first be validated as being: 
unambiguous, correct, complete, traceable, and verifiable (measurable). 


6.2 WHY VERIFICATION IS IMPORTANT TO ACCESS 5 

All requirements, if well written, are verifiable (measurable). Without being verifiable, there 
would be no way to prove to the key stakeholders that the requirements specified in this 
document could ever be met. While functional analysis is a top-down process whereby the high 
level functions are decomposed into lower level functions; requirements verification is a bottom- 
up process. In other words, to verify that a higher level requirement was met, the supporting 
lower level requirements must first be verified. Only after the supporting lower level 
requirements have been verified can it be determined that the higher level requirement was met. 


14 “Validation and Verification”, NAS Systems Engineering Manual, Version 3.0, 30 September 2004. Page 4.12-1 

15 Ibid. Page 4.12-5 
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Because verification is a bottom-up process, it can be difficult to determine what verification 
methodology should be used to verify an operational requirement, or even a functional 
requirement. It is therefore necessary to develop and verify performance level requirements, 
which by definition provide a quantifiable value that is measurable. It is for this reason, that 
verification of requirements begins at the performance level and then proceeds further up the 
requirements hierarchy until all of the functional and operational requirements have been 
verified. 

6.2.1 METHODS OF VERIFICATION 

The following verification methods can be used in determining compliance of the individual 
requirements identified in this document 16 . The four verification methods, listed in decreasing 
order of complexity, are defined as: 

• Test: This method is accomplished through systematic exercising of the application item 
under appropriate conditions, with or without instrumentation, and the collection, analysis, 
and evaluation of quantitative data. 

• Demonstration : This method includes verification accomplished by operation, adjustment, 
or reconfiguration of items performing their design functions under specific scenarios. The 
items may be instrumented and quantitative limits of performance monitored; however, only 
check sheets are required rather than recordings of actual performance data. This method is 
used when actual demonstration techniques may be used to verify compliance with a 
requirement. Observations made by engineers or instrumentation are compared with 
predetermined responses based on the requirements. Demonstration is often used to verify 
compliance with requirements in servicing, reliability, maintainability, transportability, and 
human factors engineering. 

• Analysis: This method is accomplished by technical or mathematical evaluation, 

mathematical models or simulation , algorithms, charts, circuit diagrams, and representative 
data. 

• Inspection: This method is accomplished by visually examining the item, reviewing 

descriptive documentation, and comparing the appropriate characteristics with predetermined 
standards to determine conformance to requirements without the use of laboratory equipment 
or procedures. Inspection is generally nondestructive and uses the senses of sight, hearing, 
smell, touch, and taste; simple physical manipulation; mechanical and electrical gauging and 
measurement; and other means of investigation. Inspection often verifies the physical design 
features of a system as well as construction features, workmanship, dimensions, quality, and 
physical conditions, such as cleanliness, installation, and finishing. Inspection may include 
reviews of documentation, system descriptions, and other materials to compare the actual 
system with predetermined standards. 


16 “Validation and Verification”, NAS Systems Engineering Manual, Version 3.0, 30 September 2004. Page 4.12-19 
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6.2.2 ACCESS 5 VERIFICATION APPROACH 

Since Access 5 is not going to certify any particular UAS, specific requirements for any one 
UAS are not being developed. As such, generating performance requirements is a challenge 
because the performance requirements need to apply to all, or at least most, UAS. Therefore, 
Access 5 is generating performance guidelines as opposed to performance requirements. These 
guidelines are intended to capture the key performance parameters and provide a way to quantify 
the parameters for a variety of UAS. In many cases these performance guidelines may not 
capture every end of the spectrum, but should capture the majority of cases. Several of the work 
packages developing functional requirements have gone to the next layer of functional analysis 
and have begun developing these supporting performance guidelines. These performance 
guidelines can be found in the appendix of the relevant work package specific FRD. 

In addition to including the functional requirements and supporting performance guidelines, 
several of the work-package-specific FRDs include a verification matrix identifying the 
suggested methodology intended to be used for verifying the requirement. While verification by 
flight test is not feasible for all of our requirements, flight testing could be used to verify key 
characteristics and assumptions used in developing the requirements. Validated models and 
simulation tools are also analytical verification methods that are being widely used to verify 
many of the requirements developed under Access 5. 

The method of verification identified in these verification matrices are intended for use within 
Access 5 as a way to plan what requirements should be demonstrated by different integrated 
product teams (IPT) within Access 5. For example, those requirements needing demonstration 
or test would be assumed by the Flight IPT and those requirements needing simulation would be 
assumed by the Simulation IPT. By verifying each of our functional requirements, Access 5 
hopes to gain confidence in their final proposed recommendations as well as build the necessary 
supporting body of evidence that supports these recommendations. While these verification 
methodologies could also be used by companies wishing to certify a UAS that is not the intent or 
purpose of these matrices. 
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APPENDIX A: ACRONYMS 


ADS-B 

Automatic Dependent Surveillance - Broadcast 

A/G 

Air to Ground 

AIM 

Aeronautical Information Manual 

ATC 

Air Traffic Control 

ATM 

Air Traffic Management 

BLOS 

Beyond-Line-of-Sight 

C2 

Command and Control 

C3 

Command, Control, and Communications 

CA 

Collision Avoidance 

CFR 

Code of Federal Regulations 

CM 

Contingency Management 

CNS 

Communications, Navigation, Surveillance 

CONOPs 

Concept of Operations 

CS 

Control Station 

ELOS 

Equivalent Level of Safety 

F# 

Functional Requirement # 

FAA 

Federal Aviation Administration 

FAR 

Federal Aviation Regulation 

FHA 

Functional Hazard Assessment 

FL 

Flight Level 

FMCS 

Flight Management Control System 

FRD 

Functional Requirements Document 

FRS 

Flight Recovery System 

HALE 

High Altitude Long Endurance 

HSI 

Human Systems Integration 

IFR 

Instrument Flight Rules 

IPT 

Integrated Product Team 

LOS 

Line-of- Sight 

MP 

Mission Planning 

NAS 

National Airspace System 

NASA 

National Aeronautics and Space Administration 

PTT 

Push to Talk 

RFI 

Radio Frequency Interference 

ROA 

Remotely Operated Aircraft 

UA 

Unmanned Aircraft 

UAS 

Unmanned Aircraft System 

UAV 

Unmanned Aerial Vehicle 

VFR 

Visual Flight Rules 

VHF 

Very High Frequency 

WX 

Weather 
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APPENDIX B: DEFINITIONS 


ATC Communication Link - Two-way data and/or voice link between the UAS system and 
Air Traffic Control and/or other aircraft. 

Autonomous- Operations that do not require direct pilot control. There are numerous levels 
of autonomy based upon how much the UAS pilot is involved in flying the UA. 

Civil Aircraft - Aircraft other than public aircraft. See Public Aircraft. 

Command and Control (C2) Link - The two-way data link between the Control Element and 
the UA that is used to control the UA and monitor the health/status of onboard systems. 

Concept of Operation (CONOP) - A detailed description of the means for implementing an 
operational concept that is necessary to integrate UAS into the NAS in order to accommodate 
a “file and fly” capability. 

Control Station (CS) - A site configured to allow the pilot in command of an UAS to operate 
and monitor all UAS operations conducted under his/her authority. The UAS pilot is 
considered to be an integral part of the Control Station. 

Cooperative Traffic - Traffic that broadcasts position or other information, which assists in 
detecting and assessing conflict potential. 

Sense and Avoid - The ability to sense traffic, which may be a conflict, evaluate flight paths, 
determine traffic right-of-way, and maneuver to avoid other traffic. 

Equivalent Level of Safety (ELOS) - An evaluation of any applicable airworthiness 
requirement that cannot be literally complied with, and a determination that alternative 
requirements or other compensating factors can be substituted for that requirement. The 
evaluation is often subjective, and looks at the system and/or operation to determine the risk 
to other users of the NAS and people/property on the ground. It is the intent of Access 5 to 
specify the ELOS requirements for a UAS using functional terms (i.e. functional 
requirements) and not specific design requirements. 

File and Fly - The ability of UAS pilot to file an IFR flight plan and operate in all classes of 
airspace, consistent with the regulatory criteria and operational requirements for manned 
aircraft. The flights require no pre-coordination with ATC. As with manned aircraft, UAS 
flights requiring special ATC handling in order to achieve mission objectives are not 'file and 
fly' and would be pre-coordinated with ATC. 

Flight Management Control System (FMCS) - An operable system onboard a UA that 
performs the flight control actions from input received from the pilot via the C2 link or that 
automatically operates the HALE UAS from data previously installed. 
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Flight Path - The 3 -dimensional track along which an aircraft is flying or intended to be 
flown. 

High Altitude, Long Endurance (HALE) UAS - An unmanned aircraft capable of 
performing mission objectives at an altitude above 18,000-foot mean sea level (MSL) with 
sufficient cruise capability to transit the NAS. 

Line-of-Sight (LOS) - The condition where the control element and the UAS are within 
electronic point-to-point link. 

Manned Aircraft - Aircraft piloted by a human onboard. 

Mission Area - Airspace of defined horizontal and vertical dimensions and a defined duration 
within which the UA will operate during a specified mission. The mission area is not 
associated with the flight route from/to the departure/arrival airports (see Route). 

Mission Route - The flight path to be taken within the Mission Area where sensors or other 
applications will be exercised. Changes to the Mission Route during the mission could 
adversely affect the mission objectives. 

Non-Cooperative Traffic - Traffic that does not broadcast position or other information. 

Operational Concept - A high level description of Air Traffic Management (ATM) services 
necessary to integrate UAS into the NAS by a given time horizon. 

Beyond Line of Sight (BLOS) - The condition where the control element and the UAS are 
not within electronic point-to-point link of each other. 

Pilot - The individual that monitors and controls the UAS through issuance of command and 
control input to the aircraft and that posses the applicable FAA pilot certifications and ratings. 

Route - The flight path of HALE UAS from the departure airport to the arrival airport, 
excluding any mission route and mission area. Course changes to the route have no impact on 
the mission objectives. 

Routine Operations - See "File and Fly". 

UAS Designated Airport - An airport that is capable of handling UAS operations. 

Unmanned Aircraft System (UAS) - An unmanned aircraft that is operated from a remote 
location by a pilot/operator that issues command and control instructions to the aircraft, which 
are executed by an onboard flight management control system. The UAS is comprised of 
three major elements: 1) UA, 2) Control Station and 3) Command/Control Link. 

Validation - The determination that the requirements for a system are sufficiently correct and 
complete. Correctness of a requirements statement means the absence of ambiguity or error 
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in its attributes. Completeness of a requirements statement means that no attributes have been 
omitted and those stated are essential and traceable. 

Verification - The evaluation of a system to determine that applicable requirements are met. 
The major objectives of the verification process are to confirm that: (1) the intended functions 
are correctly implemented and that the system is operationally ready and acceptable to the 
users; and (2) the requirements are satisfied. 


B-3 



APPENDIX C: UAS REQUIREMENTS WIRING DIAGRAM 


This appendix provides a wiring diagram of the UAS Functional Requirements showing 
traceability throughout every level of our UAS requirements. Analyst Pro software was used 
to generate this diagram and is currently being used to manage and track all of the Access 5 
functional requirements. This requirements management software tool provides effective 
tracking, importing, exporting, base lining, reporting, diagramming, graphing and 
requirements traceability. While not as powerful as some of its industrial counterparts, 
Analyst Pro has the capability to directly link requirements from one level to requirements at 
another level, providing easy traceability of each requirement. 

With one click of the mouse, a systems engineer can instantly see all the requirements 
attached to a single requirement. The traceability output can be in the form of tables or even 
diagrams which make it easier and quicker to analyze. The importing and exporting features 
make transferring requirements from other documents such as Word and Excel faster and 
quicker without having to cut and paste between applications. Reports are extremely flexible 
and adaptable with many choices including number and titles of columns, table or text formats 
and many field indicators. The requirements can be tightly grouped into a table or spelled out 
in great detail individually with many attributes. The diagram feature allows easier and faster 
understanding of a tree of functions, systems, or operations by graphically representing a tree 
from beginning to end. 
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Fly Safely in the NAS 


5.1 AVIATE 


► | 5.1.1 LAUNCH] 


5.2 NAVIGATE 


5. 1.1.1 Abort Launch 


> | 5.1.2 MANEUVER] 


5. 1.2.1 Maneuver in the Air 


i- » | 5. 1.2. 1.1 Change altitude | 

| » | 5. 1.2. 1.2 Change heading | 

L > | 5. 1.2. 1.3 Change speed | 

> | 5. 1.2. 2 Maneuver on the Surface | 

; 5. 1.2. 2.1 Change ground path | 

> | 5. 1.2. 2. 2 Change speed | 


> |5.2.1 DEVELOP MISSION PLAN] 

► | 5.2. 1.1 Access Mission Plan Data (MP1) | 
j- > | 5 . 2 . 1 . 2 Evaluate Mi ssi on Plan Data ( MP2 ) | 

► | 5. 2. 1.3 Create Mission Data (MP3) ~| 

I- » | 5.2. 1.4 Record Mission Plan (MP4) | 

1 » | 5.2.1. 5 Provide Information to ATM System (MP5) | 

> | 5.2.2 IDENTIFY CURRENT POSITION | 


5.2.3 DETERMINE HOWTO TRANSITION TO 
DESTINATION 




5.2.4 PRODUCE NAVIGATION COMMAND 




^.1.2.3 Enable Pilot to Maneuver UA (HSI FI) | > | 5.2.5 EXECUTE NAVIGATION COMMAND 

► | 5.2.6 CONVEY NAVIGATIONAL STATUS 
► | 5.2.6 CONVEY NAVIGATIONAL STATUS ~| 
► | 5.2.7 UPDATE FLIGHT PLAN] 

► [~5.2.7.1 Pilot Updates to Flight Plan (HSI F5) | 


5. 1.2.4 Enable Pilot to Monitor 
Flight Operations (HSI F2) 


> | 5.1.3 CRUISE | 

> | 5.1.4 RECOVER] 

| > | 5.1 .4.1 Recover during normal operations | 

I > | 5.1 .4.2 Recover during non-normal operations | 
L » | 5. 1.4. 3 Go Around ~| 

> | 5.1.5 MAINTAIN STRUCTURAL INTEGRITY ~| 


5.3 COMMUNICATE 

[ » | 5.3.1 COMMUNICATE WITHIN THE UAS | 

| » | 5. 3. 1.1 Transmit Information within the UAS | 
1 ► [ 5.3.1.2 Receive Information within the UAS | 
l » | 5.3.2 COMMUNICATE OUTSIDE THE UAS | 


5.3.2. 1 Tune Radio to the Assigned Channel 
(C3-ATCF1) 


5. 3. 2. 2 Receive/Monitor ATC Voice Channel 
Activity (C3-ATC F2) 


5. 3. 2. 2.1 Receive using Human Systems Interface 
(HSI F6) 


> | 5. 3. 2. 3 Transmit Voice (C3-ATC F4] | 

[ > | 5. 3. 2. 3.1 Transmit Indication Signal (C3-ATC F3) | 


5. 3. 2. 3. 2 Transmit only during Transmit Signal 
Indication (C3-ATC F5) 


> | 5. 3. 2. 3. 3 Entry into a Talk Group (C3-ATC F6) 


5.3.2. 3.4 Transmit using Human Systems Interface 
(HSI F6) 


5. 3. 2. 4 Coexist with other Existing NAS Systems 
(C3-ATC F7) 


[ > | 5. 3. 2.4.1 Limit Interference (C3-ATC F7a) ~] 

L > | 5. 3. 2.4. 2 Use Allocated Spectrum (C3-ATC F7b) ~| 
► | 5.3.2 5 Transmit transponder data | 

► | 5. 3. 2.5.1 Select / Modify transponder code | 

► | 5. 3. 2. 5. 2 Enable / Disable reporting capability ~| 

> | 5. 3. 2. 6 Receive transponder data | 


5.4 AVOID HAZARDS 


5.4.1 AVOID COLLISIONS WITH THE SURFACE - ] 


5 .4. 1.1 Avoid collisions with terrain. 




5.4. 1.2 Avoid collisions with obstructions on the 
ground 


5.4.2 AVOID COLLISIONS WITH OTHER 
AIRCRAFT 


5.4.2. 1 Avoid collisions by being detectable to other 
traffic 


> | 5. 4. 2. 2 Avoid collision threats identified by ATC 


5. 4. 2. 3 Avoid collision threats identified by Collision 
Avoidance System 


> | 5.4.2. 3.1 Detect Traffic (CA FI) | 

►15.4.2.3.2 Track Traffic (CA F2) | 

► | 5.4. 2. 3.3 Evaluate Collision Potential (CA F3) | 

► | 5.4.2. 3.4 Prioritize Collision Threats (CA F4) | 

► | 5.4. 2. 3. 5 Determine Avoidance Maneuver (CA F5) | 


5.4. 2. 3.5.1 Convey threat information to the Pilot 
(HSI F7a) 


► | 5.4. 2. 3. 6 Command Maneuver (CA F6) | 


► | 5.4. 2. 3. 7 Execute Maneuver (CA F7) | 

► | 5.4.3 AVOID HAZARDOUS WEATHER | 

■ » | 5.4. 3.1 Maintain Weather Awareness | 

► | 5.4.3. 1.1 Gather Weather Information | 


5.5 CROSS-CUTTING 


► | 5.5.1 COMMAND / CONTROL~| 

► | 5.5.1. 1 Exchange Information (C2 FI) | 

» | 5.5.1. 1.1 Uplink Information (C2 FI . 1) | 

► | 5.5. 1.1. 2 Downlink Information (C2 FI. 2) ] 

► ! 5.5.1. 1.3 Consistent Operations (C2 FI. 3) | 

► | 5.5.1. 2 Control UA Flight Operations (C2 F2) | 


5.5.1 .2.1 Provide Situational Awareness and Health 
& Status (C2 F2.1) 


► | 5.5. 1 .2.2 Provide C2 Directives (C2 F2.2) | 

> | 5.5.1. 2.3 Prioritize Information Exchanges (C2 F2.3) | 

► | 5. 5. 1.2.4 Coexist within the NAS (C2 F2.4) | 

> | 5.5.1 .2.5 Distinguish between UA's (C2 F2.5) ~| 


5. 5. 1.3 Prevent unauthorized operation of the UAS 
(C2 F3) 


► ! 5. 5. 1.3.1 Physical Security (C2 F3.1) | 

► | 5.5.1. 3.2 Link Security (C2 F3.2) | 

► ! 5.5.1 .3.3 Link Interference (C2 F3.3) | 

► | 5.5. 1.4 Provide Link Connectivity (C2 F4) | 


5.4. 2. 3. 6.1 Control the Collision Avoidance System 
(HSI F7b) 


5.5.1 .4.1 Transitioning between LOS/BLOS (C2 
F4.1) 


5.5.1 .4.2 Transitioning between Control Stations (C2 
F4.2) 


► | 5.5.2 MANAGE CONTINGENCIES'] 

• ► ! 5 . 5 . 2 . 1 I denti fy System Status ~~| 


> | 5.4. 3. 1.1.1 Request weather information (HSI F8b) | 


5. 5. 2. 1.1 Convey System Status to the Pilot (HSI 
F3) 


5. 4.3.1 .1 .2 Convey weather information to the UAS 
Pilot (HSI F8a) 


- 5 4.3.2 Coordinate Weather Avoidance Maneuver 


> 5.4.3 3 Command Weather Avoidance Maneuver 


> | 5 . 5 . 2. 2 Determine Contingency Event | 
> | 5 . 5 . 2 . 3 Prioritize Contingency Events | 
► | 5 . 5 . 2 . 4 Produce Mitigation Command | 


5. 4. 3. 3.1 Control the Weather Awareness System 
(HSI F8c) 


5. 5. 2.4.1 Enable Pilot to Manage Contingencies 
(HSI-F9) 


> | 5. 5. 2. 5 Execute Mitigation Command | 


► | 5.4. 3.4 Execute Weather Avoidance Maneuver | 


Figure C.l: UAS Functional Requirements Wiring Diagram 


C-2 


APPENDIX D: OPERATIONAL/FUNCTIONAL TRACEABILITY 
MATRIX 


This Appendix provides a traceability matrix between the Operational Requirements found in 
the Access 5 CONOPs and the Functional Requirements found within the Access 5 FRD. 
Colu mn s 1 and 2 of the table list all of the Functional Requirements and column 3 provides 
those operational requirements that are supported by the functional requirement listed in that 
row. 


Table D.l: Operational / Functional Traceability Matrix 


Functional 

Requirement 

Number 

Functional 

Requirement 

Operational 

Requirement 

Number 

5.1 

Aviate functional requirements 


5.1.1 

Launch 

01.1, 01.2, 01.3, 
02.2 

5.1. 1.1 

Abort Launch 

01.3 

5.1.2 

Maneuver 

01.1, 01.2, 01.3, 
02.2 

5.1 .2.1 

Maneuver in the Air 

01.1, 01.2, 01.3, 
02.1, 02.3 

5.1 .2.1 .1 

Change altitude 

01.2 

5.1. 2. 1.2 

Change speed 

01.2 

5.1. 2. 1.3 

Change heading 

01.2 

5.1 .2.2 

Maneuver on the Surface 

01.1, 01.2, 01.3, 
02.1, 02.3 

5.1 .2.2.1 

Change ground path 

01.2 

5.1. 2.2.2 

Change speed 

01.2 

5.1 .2.3 

Enable Pilot to Maneuver UA (HSI FI ) 

01.2, 02.5 

5.1. 2.4 

Enable Pilot to Monitor Flight Operations (HSI F2) 

01.2, 02.5 

5.1.3 

Cruise 

01.1, 01.2, 02.2, 
02.3 

5.1.4 

Recover 

01.1, 01.2, 02.2, 
02.3 

5.1 .4.1 

Recover during normal operations 

01.2, 01.3 

5.1. 4.2 

Recover during non-normal operations 

01.2, 01.3 

5.1 .4.3 

Go Around 

01.3 

5.1.5 

Maintain Structural Integrity 

01.1, 01.2, 01.3 

5.2 

Navigate functional requirements 


5.2.1 

Develop Flight plan 

02.1, 02.3 

5.2.1. 1 

Gather Information (MP1) 

02.3 

5.2.1 .2 

Create a Mission Profile (MP2) 

02.3 

5.2.1 .3 

Provide Mission Information to the UA (MP3) 

02.3 

5.2.1. 4 

Provide Flight Information to the NAS (MP4) 

02.3 

5.2.2 

Identify current Position 

02.1, 02.3, 02.4 

5.2.3 

Determine Howto transition to Destination 

02.1, 02.3, 02.4 

5.2.4 

Produce Navigation Command 

02.1, 02.3, 02.4 
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5.2.5 

Execute Navigation Command 

01.2, 01.3, 02.1 

5.2.6 

CONVEY NAVIGATIONAL STATUS 

02.1, 02.3 

5.2.6. 1 

Convey Navigational Information to the Pilot (HSI F4) 

02.5 

5.2.7 

Update Flight Plan (HSI F5) 

02.1, 02.3 

5.2.7. 1 

Pilot Updates to Flight Plan (HSI F5) 

02.5 

5.3 

Communicate functional requirements 


5.3.1 

Communicate Within the UAS 

01.2, 01.3, 02.7 

5.3.1. 1 

Transmit Information within the UAS 

01.2, 01.3 

5.3.1 .2 

Receive Information within the UAS 

01.2, 01.3 

5.3.2 

Communicate Outside the UAS 

02.1, 02.4, 02.7 

5.3.2. 1 

Tune Radio to the Assigned Channel (C3-ATC FI ) 

02.1, 02.4 

5. 3. 2. 2 

Receive/Monitor ATC Voice Channel Activity (C3-ATC 
F2) 

02.1, 02.4 

5.3.2.2.1 

Receive using Human Systems Interface (HSI F6) 

02.1, 02.4, 02.5 

5. 3. 2. 3 

Transmit Voice (C3-ATC F4) 

02.1, 02.4, 02.7 

5.3.2.3.1 

Transmit Indication Signal (C3-ATC F3) 

02.1, 02.4 

5. 3. 2. 3. 2 

Transmit only during Transmit Signal Indication (C3- 
ATC F5) 

02.1, 02.4 

5. 3. 2. 3. 3 

Entry into a Talk Group (C3-ATC F6) 

02.1, 02.4 

5. 3. 2. 3.4 

Transmit using Human Systems Interface (HSI F6) 

02.1, 02.4, 02.5 

5. 3. 2.4 

Coexist with other Existing NAS Systems (C3-ATC F7) 

01.3, 02.7 

5. 3. 2.4.1 

Limit Interference (C3-ATC F7a) 

01.3, 02.7 

5. 3. 2.4. 2 

Use Allocated Spectrum (C3-ATC F7b) 

01.3, 02.7 

5. 3. 2. 5 

Transmit transponder data 

02.1, 02.4, 02.7 

5.3.2.5.1 

Select / Modify transponder code 

02.1, 02.4 

5. 3. 2. 5. 2 

Enable / Disable reporting capability 

02.1, 02.4 

5. 3. 2. 6 

Receive transponder data 

02.4 

5.4 

Avoid hazards functional requirements 


5.4.1 

Avoid collisions with the Surface 

01.3 

5.4.1. 1 

Avoid collisions with terrain. 

01.3 

5.4.1. 2 

Avoid collisions with obstructions on the ground 

01.3 

5.4.2 

Avoid collisions with other aircraft 

01.3 

5.4.2. 1 

Avoid collisions by being detectable to other traffic 

01.3, 02.4 

5.4. 2. 2 

Avoid collision threats identified by ATC 

01.3, 02.4 

5.4. 2. 3 

Avoid collision threats identified by Collision Avoidance 
System 

01.3, 02.4, 02.7 

5.4. 2. 3.1 

Detect Traffic (CA FI ) 

01.3, 02.4 

5.4. 2. 3. 2 

Track Traffic (CA F2) 

01.3, 02.4 

5.4. 2. 3. 3 

Evaluate Collision Potential (CA F3) 

01.3, 02.4 

5.4. 2. 3.4 

Prioritize Collision Threats (CA F4) 

01.3, 02.4 

5.4. 2. 3. 5 

Determine Avoidance Maneuver (CA F5) 

01.3, 02.4 

5.4. 2. 3. 6 

Command Maneuver (CA F6) 

01.3, 02.4 

5.4. 2. 3. 7 

Execute Maneuver (CA F7) 

01.2, 01.3, 02.1, 
02.4 

5.4.3 

Avoid severe weather 

01.3, 02.1 

5.4.3. 1 

Maintain Weather Awareness 

01.3, 02.1 

5.4. 3.1 .1 

Gather Weather Information 

01.3, 02.1 

5.4.3. 1 .2 

Evaluate Potential for Weather Conflicts 

01.3, 02.1 

5.4. 3. 2 

Coordinate Weather Avoidance Maneuver 

01.3, 02.1 
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5.4. 3. 3 

Command Weather Avoidance Maneuver 

01.3, 02.1 

5.4. 3. 3.1 

Control the Weather Awareness System 

01.3, 02.1, 02.5 

5.4. 3.4 

Execute Weather Avoidance Maneuver 

01.2, 01.3, 02.1 

5.5 

Cross-Cutting Functional Requirements 


5.5.1 

Command / Control 

01.3, 02.5, 02.7 

5.5.1. 1 

Exchange Information (C2 FI) 

02.7 

5.5.1. 1.1 

Uplink Information (C2 F1.1) 

02.7 

5.5.1. 1.2 

Downlink Information (C2 FI. 2) 

02.7 

5.5.1. 1.3 

Consistent Operations (C2 FI. 3) 

02.7 

5.5.1 .2 

Control UA Flight Operations (C2 F2) 

01.3, 02.5, 02.7 

5.5.1 .2.1 

Provide Situational Awareness and Health & Status 
(C2 F2.1 ) 

01.3 

5.5.1 .2.2 

Provide C2 Directives (C2 F2.2) 

02.5 

5.5.1 .2.3 

Prioritize Information Exchanges (C2 F2.3) 

01.3 

5.5.1. 2.4 

Coexist within the NAS (C2 F2.4) 

02.7 

5.5.1 .2.5 

Distinguish between UA’s (C2 F2.5) 

01.3 

5.5.1 .3 

Prevent unauthorized operation of the UAS (C2 F3) 

01.3 

5.5.1 .3.1 

Physical Security 

01.3 

5.5.1 .3.2 

Link Security (C2 F3.2) 

01.3 

5.5.1 .3.3 

Link Interference (C2 F3.3) 

01.3 

5.5.1 .4 

Provide Link Connectivity (C2 F4) 

01.3, 02.7 

5.5.1 .4.1 

Transitioning between LOS/BLOS (C2 F4.1) 

01.3, 02.7 

5.5.1. 4.2 

Transitioning between Control Stations (C2 F4.2) 

01.3, 02.7 

5.5.2 

Manage Contingencies 

01.3, 02.6 

5.5.2. 1 

Identify System Status 

01.3, 02.6 

5.5.2.1.1 

Convey System Status to the Pilot (HSI F3) 

01.3, 02.5, 02.6 

5. 5. 2. 2 

Determine Contingency Event 

01.3, 02.6 

5. 5. 2. 3 

Prioritize Contingency Events 

01.3, 02.6 

5. 5. 2.4 

Produce Mitigation Command 

01.3, 02.6 

5. 5. 2.4.1 

Enable Pilot to Manage Contingencies (HSI-F9) 

01.3, 02.5, 02.6 

5. 5. 2. 5 

Execute Mitigation Command 

01.2, 01.3, 02.6 
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